Description

What is the purpose of this pull request?

This pull request:

• Corrects the smoke-test argument literals in the docs/types/test.ts files of @stdlib/namespace/pkg2related and @stdlib/namespace/standalone2pkg to match each function's documented @param input type.

Namespace summary

• Target namespace: @stdlib/namespace
• Member count: 8 (all non-autogenerated)
• Features analyzed: file tree, package.json shape/scripts/stdlib keys, manifest.json presence, README heading list, README ## Usage / ## Notes bodies, docs/repl.txt bodies, docs/types/index.d.ts shape, docs/types/test.ts smoke-test argument literal, docs/usage.txt and etc/cli_opts.json shape, bin/cli structure, lib/index.js re-export style, lib/main.js public signature, validation prologue, error construction, and dependency set.
• Features with clear majority (≥75% conformance): package.json top-level key set (100%); scripts key set (100%, all empty); file-tree entries README.md, LICENSE, package.json, bin/cli, benchmark/benchmark.js, examples/index.js, lib/index.js, lib/main.js, docs/repl.txt, docs/types/index.d.ts, docs/types/test.ts, docs/usage.txt, etc/cli_opts.json, test/test.cli.js, test/test.js, datapackage.json, scripts/build.js, data/data.json (all 100%); docs/usage.txt and etc/cli_opts.json bodies (100%); errorConstruction: format (100%); validationPrologue: [!isString → TypeError via format] (100%); returnKind: value (100%); jsdocShape.throwsTags: [{type: TypeError}] (100%); docs/types/test.ts smoke-test argument matches the function's @param type (6/8 = 75%).
• Features without clear majority (excluded from drift detection): README section list — 6/8 lack ## Notes, but the two packages that carry it (pkg2alias, pkg2related) genuinely document dual-format input support and were ruled intentional; keyword arrays (variation follows semantic role — aliases is a dataset package, standalone* packages tag standalone); data/data.csv vs data/data.txt (semantic — mapping vs list); lib/index.js re-export variable name (7/8 use the function name, aliases uses main; the modern convention is main, so the numeric majority is legacy drift, not a target).

Per outlier package

@stdlib/namespace/pkg2related

pkg2related in docs/types/test.ts invokes the function with 'base.sin', an alias rather than the package name its @param pkg documents. Replace both occurrences with '@stdlib/math/base/special/sin', matching the literal already used in pkg2alias and pkg2standalone at the same call site. $ExpectType and $ExpectError assertions are untouched; only the string literal changes.

@stdlib/namespace/standalone2pkg

docs/types/test.ts invoked standalone2pkg( 'base.sin' ) and standalone2pkg( 'base.sin', 'beep' ), passing an alias where @param pkg documents a standalone package name. Replace both literals with '@stdlib/math-base-special-sin', matching the ## Usage example in the README. $ExpectType and $ExpectError assertions still exercise string; no runtime code, tests, or examples change.

Validation

Checked:

• Structural feature extraction across all 8 members (file tree, package.json shape, README section list and body per section, docs/repl.txt body, docs/types/index.d.ts shape, docs/types/test.ts shape, docs/usage.txt / etc/cli_opts.json bodies, bin/cli structure, and test/benchmark/example filenames).
• Semantic feature extraction across all 8 lib/main.js and lib/index.js files (public signature, return kind, validation prologue, error construction, JSDoc shape, dependency set from require calls).
• Adversarial verification of the two candidate corrections by an independent agent: confirmed the two outlier packages' documented input types (package name / standalone package name) are demonstrably not aliases; confirmed the See Also generator (_tools/remark/plugins/remark-stdlib-related/lib/transformer.js) derives package names from file.dirname, not from test.ts literals; confirmed no eslint rule inspects literal values; confirmed the sibling pkg2alias / pkg2standalone test.ts files already use the target literal in the same call position.
• Cross-run dedup: no open or recently-merged PR targets @stdlib/namespace or proposes the same fix.

Deliberately excluded:

• pkg2related's lib/main.js returns PKG_TO_RELATED[ pkg ] (no .slice()) in the standalone2pkg fallback branch while returning PKG_TO_RELATED[ pkg ].slice() in the primary branch — this is a real defensive-copy bug, but the fix would change observable behavior (a caller mutating the returned array would no longer mutate the internal table) and is therefore out of scope for a drift-detection routine restricted to mechanical, behavior-preserving fixes. Logged in the local drift report for follow-up.
• README ## Notes section on pkg2alias and pkg2related — semantically justified (documents dual-format input support delegated through standalone2pkg), not drift.
• data/data.csv vs data/data.txt — semantic difference (mapping vs list), not drift.
• lib/index.js re-export variable name (7/8 use function name, aliases uses main) — the numeric majority is the legacy convention and applying it would regress aliases toward older style.
• See Also README sections — auto-populated generator artifact per the invariant.
• Any change to public signatures, tests, benchmarks, examples, or observable behavior.

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

Random namespace pick, seed 2616902172. Eligibility criteria: ≥8 non-autogenerated direct child packages under lib/node_modules/@stdlib/; 123 candidate namespaces qualified. The chosen namespace had 8 members, none autogenerated. Full per-feature drift report saved locally alongside the run.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

This PR was authored by Claude Code running a cross-package drift-detection routine: the namespace (@stdlib/namespace) was picked at random (seed 2616902172), structural and semantic features were extracted for every member, majority patterns were computed at a 75% conformance threshold, and an independent adversarial verification agent confirmed each correction before it was applied. Only the two docs/types/test.ts files in pkg2related and standalone2pkg were changed — mechanical string-literal substitution to match each function's documented @param type.

@stdlib-js/reviewers

Generated by Claude Code